Nun, der Dialogbetrieb ist ein klassischer, sogenannter Mehrzugangsbetrieb und unter dieser

Betriebsart da fallen zwei weitere Spezialisierungen, nämlich einerseits

der Teilnehmerbetrieb, den wir so als Timesharing-Betrieb kennen, und dann der Teilhaberbetrieb.

Beide werden wir uns jetzt mal ein bisschen genauer anschauen.

Dialogbetrieb allgemein bedeutet, dass man Benutzereingaben hat und deren

Verarbeitung die Wechselnsicht nimmt anhaltend immer ab. Das ist so ein

conversational mood, wie man auch im Angriff amerikanischen denn sagen würde.

Nun wir haben EA, also ein Ausgabe-intensive Anwendungsprogramm, die

sollen mit Benutzern interagieren. Die Benutzer sitzen an Dialogstationen.

Das sind Datensichtgeräte, Tastaturen, Mäuse und andere Tablets oder Dinge sind

denn später noch dazugekommen. Man muss sich das so vorstellen, dass

hier Räume existieren, wo dann so hunderte von Dialogstationen platziert

sind mit den entsprechenden Gerätschaften, die denn alle an einen

Zentralrechner angeschlossen sind. Das ist also nicht so eine Situation, wie wir

sie typischerweise kennen, wo denn jeder seinen kleinen Rechner, seinen personal

Computer unter dem Tisch hat und der sitzt eigentlich alleine an diesem

Rechner dran über ein Datensichtgerät und Tastatur inklusive Maus kann

damit dem Rechensystem denn in Interaktion treten.

Denn Dialogbetrieb bedeutet Mainframe-Betrieb, Großrechnerbetrieb vor

allen Dingen eben auch so ist es auch entstanden. Eine riesen Anzahl von solchen

Dialogstationen an einen zentralen Rechner, den Mainframe sozusagen, den

Großrechner. Nun damit war natürlich grundsätzlich erst mal innerhalb des

Rechensystems eben auch in einer anderen Form von Einplanung notwendig und

denn diese Interaktion zu unterstützen. Also interaktionsloser Betrieb wie bei

Stapelbetrieb stand also hier nun wirklich nicht mehr im Vordergrund und

damit kann man eben nicht so eine Konversation sozusagen zwischen Mensch

und Maschine denn betreiben. Das heißt also eine dynamische Einplanung auf der

Scattling-Ebene, die denn so ausgelegt war, dass sie gerade diese interaktiven

Prozesse denn eben bevorzugt behandelt hat. Also man hat schon erlaubt, dass da

eben auch weniger interaktive rechenintensive Prozesse stattfinden

können. Die sollten dann aber nicht bevorzugt praktisch an diese Rechner

Ressourcen rankommen. Das heißt eher so im Hintergrund dann

ablaufen. So eine Ausgabeoperation führte denn dazu, dass eine recht schnelle

Neueinplanung von Prozessen durchgeführt wurde und das wechselte sich dann eben

immer stark ab. Also die Aktivierung dieser einzelnen Prozesse, sodass dann

eben die Nutzer, die an dem Rechensystem, also an diesen Dialogstationen, denn

sitzen oder saßen, eben eine ziemlich schnelle Reaktion auf ihre individuellen

Eingaben erfahren. Das bedeutet in dem System drin selbst, dass wenn

wir eine Eingabe machen, wenn wir etwas auf die Tastatur halt eingeben, dann

müssen die Prozesse oder der eine Prozess, der gerade mit dieser Tastatur

in Verbindung steht, denn ziemlich prompt eingelastet werden. Schnell eingelastet

werden, sodass er in der Lage ist, eben doch schnell in Interaktion zu treten, die

Daten zu verarbeiten und eine Reaktion darauf dann abgeben zu können.

Problem ist eigentlich, der Wesentliche, dass zum Anfang diese Art von

Rechenbetrieb, diese Dialogführungen, zusatz zum Stapelbetrieb war, also intern

drin, liefen denn eher so starke, träge Operationen ab, die stark

interaktionslos waren. Ein anderer Punkt war, dass diese, man ist jetzt von mehreren

Online-Prozessen ausgegangen, dass wenn jetzt einer dieser Prozesse einfach

anfängt, die CPU zu monopolisieren, also ihr habt vielleicht eine Endlosschleife,

dass das natürlich ein Problem für die Interaktion mit den anderen Prozessen